Apparatus and method for efficient TDMA bandwidth allocation for TCP/IP satellite-based networks

ABSTRACT

A communication system balances message traffic between return channel groups and within the groups, so that the user does not control the specific transmission frequency used. Uplink frequencies and bandwidths for the return channels are set by the system in a return channel control message in the broadcast signal so as to account for system and return channel group loading, and to account for user message backlogs. An initial transmission from a remote user may be made using an ALOHA-type burst signal that provides a message backlog to the control station, and is made on a frequency determined from a randomly weighted, load-based frequency selection process. The system, and not the individual users determine the frequency and channel allocations. For large backlogs or priority users, periodic bandwidth is provided. A method for balancing loads among and between groups of return channels in the communication system includes requesting return channel bandwidth in an uplink message from a remote user to a control station. The uplink message may include a both a backlog indicator and a bandwidth allocation request provided to a Network Operations Center (NOC) which can be used to set the return channel bandwidth and frequency for the remote uplink. A user message is transmitted on the designated return channel frequency using bandwidth allocated in accordance with the backlog indicator and a bandwidth allocation request so that traffic loads are maintained in balance between established return channel frequency groups, and within each return channel frequency group.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit under 35 U.S.C. § 119(e) of U.S.Provisional Application of Kelly et al. entitled “Efficient TDMABandwidth Allocation for TCP/IP Satellite-Based Networks”, Ser. No.60/188,375, filed on Mar. 10, 2000, and of U.S. Provisional Applicationof Kelly et al. entitled “Two-way Communications System and Method”,Ser. No. 60/197,246, filed on Apr. 14, 2000, the entire contents of eachbeing incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to a bandwidth allocation scheme forTime Division Multiple Access (TDMA) systems, and specifically toefficient bandwidth allocation for Transmission ControlProtocol/Internet Protocol (TCP/IP) systems over a TDMA-based satellitenetwork.

2. Description of the Related Art

Using satellites for Internet and Intranet traffic, in particularmulticasting of digital video through use of Digital Video Broadcast(DVB) and two-way broadband communication has recently received a greatdeal of attention. Satellites can help relieve Internet congestion andbring the Internet and interactive applications to countries that do nothave an existing network structure, as well as provide broadbandinteractive application support.

As one means of using satellite technology in this growing field, verysmall aperture terminals (VSATs) provide rapid and reliablesatellite-based telecommunications between an essentially unlimitednumber of geographically dispersed sites. VSAT technology hasestablished effective tools for LAN internetworking, multimedia imagetransfer, batch and interactive data transmission, interactive voice,broadcast data, multicast data, and video communications.

The Internet Protocol (IP) is the most commonly used mechanism forcarrying multicast data. Examples of satellite networks capable ofcarrying IP Multicast data include Hughes Network System's PersonalEarth Station (PES) VSAT system and Hughes Network System's DirecPC®system. Combining VSAT delivery with standards-based IP multicastensures users a less expensive and more flexible approach to achievinghigh-quality, real-time broadcasting. Satellite Digital Video Broadcast(DVB) technology and the Internet Protocol (IP) have converged(“IP/DVB”) to allow users transparent access to a variety of broadbandcontent, including live video, large software applications, andmedia-rich web sites.

In support of these developments, VSAT systems, such as the PersonalEarth Station mentioned above, allow commercial users to access one of agenerally limited number of satellite return channels to support two-waycommunication. The choice of return or inbound channel is usuallyrestricted to only a group of only a few of the possible channelspreconfigured by a combination of hardware and/or software limitations.Some commercial systems may use a VSAT system terminal for Internetaccess to receive HTTP responses via the outbound satellite broadcastchannel, and may send HTTP requests to the Internet through a VSATinbound channel. Unfortunately, as these systems are mass-marketed toconsumers and the number of users increases, the generally limitednumber of inbound channels can experience congestion and reduced userthroughput as a result of an increasing number of users competing for afinite number of inbound satellite channels. The potential benefits thatVSAT technology bring to consumers in the area of broadband delivery arenecessarily diminished by the limited bandwidth, available on theinbound channels.

Slotted-time approaches for the uplink channels are commonly used andmay be based on Time-Division Multiple Access (TDMA). TDMA is atechnique for allocating multiple channels on the same frequency in awireless transmission system, such as a satellite communication system.TDMA allows a number of users to access a single radio frequency (RF)channel without interference by allocating unique time slots to eachuser within each channel. Access is controlled using a frame-basedapproach, and precise system timing is necessary to allow multiple usersaccess to the bandwidth (i.e. time slot access) necessary to transmitinformation in a multiplexed fashion on the return channel.

Transmissions are grouped into frames, with a frame synchronization(“sync”) signal usually being provided at the beginning of each frame.Following the frame sync, there are a number of time “slices” within theframe for burst transmissions. In the simplest case, one time slicerepresenting a fixed amount of bandwidth is allocated to each of theusers having the need to transmit information. Each TDMA user gets aspecific time slot (or slots) in the channel, and that time slot isfixed for the user during the transmission. In more complicated systems,multiple time slices are made available to users based on transmissionneed or a prioritization scheme. After all time slices have elapsed,another frame synchronization signal is transmitted to restart thecycle. However, even if the user has nothing to transmit, the time slotis still reserved, resulting in inefficient utilization of the availablebandwidth.

TDMA requires a method for timing of the epochs of burst transmission toreduce burst overlap and consequent “collisions” of different users'transmissions. In addition, providing each remote user access to neededuplink bandwidth (essentially equivalent to slot access) becomes moredifficult when sharing a larger number of different inroute or uplinkchannels among a large number of users. With TDMA, each VSAT accesses acontrol node via the satellite by the bursting of digital informationonto its assigned radio frequency carrier. Each VSAT bursts at itsassigned time relative to the other VSATs on the network. Dividingaccess in this way—by time slots—allows VSATs to make the most efficientuse of the available satellite bandwidth. Like most TDM-based protocols,bandwidth is available to the VSAT in fixed increments whether or not itis needed, as discussed above. Establishing an equitable allocation ofuplink bandwidth for each of the uplink or inroute users is difficultdue to uneven (i.e. fluctuating heavy or light) loading within a groupof uplink channels, and due to relatively uneven loading between groupsof uplink channels.

FIG. 1 provides an exemplary conventional satellite communication system100 which limits each of “k” possible remote users 140 to one returnchannel group 160 out of “n” available groups. Each of the n returnchannel groups 160 could, for example, have “m” return channelfrequencies available, thereby allowing each remote user to uplink onone of the m frequencies, as access is granted. Uplink timinginformation may be derived from transceiver 150 using the receivedoutroute broadcast 120 transmitted by earth station 110 throughsatellite 130. Outroute broadcast 120 may include several informationstreams each received by a portion of remote users 140. Timing signalsfor each remote user may be derived from its associated informationstream, and independent from the uplink timing information, and furthermay be applicable only for the return channel group 160 assigned to theparticular remote user 140. In addition, internet/intranet access may beprovided to remote users 140 through earth station 110 and gateway 170.

As the use of two-way satellite networks has expanded into the consumermarket, industry has further pursued internetworking of multiplesatellite-broadcast networks and their associated independent inroute(“inbound”) or uplink channels. As the market expands, the number ofpossible uplink users further increases, and the previous approaches toallocation of return channel bandwidth to users in fixed, predetermineduplink channel groups necessarily requires additional hardware andsystem complexity in order to accommodate the increased uplink demand.If return channel groups base their frame timing on a particularsatellite broadcast which is not common to all remote users acrossreturn channel groups, then users are necessarily limited to theirpre-assigned return channel group, thus limiting flexibility.

Further, this approach becomes increasingly inefficient both in terms ofhardware allocation, cost, and uplink channel bandwidth utilization,since many of the available groups of uplink channels may be eitherheavily or lightly loaded or subject to load imbalance relative to otherinroute groups. This could be the result of each user beinghard-configured for access to a specific inroute channel, or to only alimited number of channels, whether due to hardware or softwarelimitations, or the frame timing considerations discussed above. Thisproblem is exacerbated by the bursty and somewhat unpredictable natureof such transmissions, which also may result in inefficient use of theavailable bandwidth.

Several solutions for bandwidth allocation are available for “casualuse”, or non-critical uplink systems, and may be used in conventionalsatellite communication 100 shown in FIG. 1. For example, well-knownALOHA techniques are employed in order to minimize overhead associatedwith allocation of bandwidth to users when there is no data to transmit.ALOHA was developed to coordinate and arbitrate access to a sharedcommunication channel. Although originally applied in terrestrial radiobroadcasting, the system has successfully been implemented in satellitecommunication systems. A medium access method, such as ALOHA, isintended to prevent two or more systems from transmitting at the sametime on a shared medium. There must be some method for handlingso-called “collisions”. In the ALOHA system, a system transmits wheneverdata is available to send. If another system transmits at the same time,a collision occurs, and the frames that were transmitted are lost.However, a system can listen to broadcasts on the medium, even its own,or await an acknowledgement from the destination station to determine ifthe frames were actually transmitted.

However, so-called pure ALOHA has about seven percent bandwidthefficiency, meaning that approximately 14 times the required bandwidthmust be allocated. Further, the delays to users actually having trafficto transmit may not be acceptable in time-sensitive applications,particularly because the ALOHA technique “wastes” bandwidth, and hencetime slots, on users having no or low traffic load to transmit.

The pure ALOHA technique is simple and elegant, but another methodcalled slotted ALOHA, or random access mode, was devised to double thetraffic capacity. In the slotted ALOHA scheme, distinct time slots arecreated in which users can transmit a single frame in a packet, but onlyat the beginning of a slot. Thus, the transmitter will have to bufferdata until the beginning of the next slot period. For example, a controlnode can emit a signal at the start of each slot to let all other usersknow when the slot is available. By aligning frames on slots, overlapsin transmissions are reduced. However, users must wait a fraction of asecond for the beginning of a time slot before they can transmit. Also,data may be lost if users contend for the same slot, but not as muchdata as would be lost in pure ALOHA. However, tests have shown thatslotted ALOHA has a performance advantage, and is best suited for short,“bursty” messages in applications that require fast response times, suchas point of sale credit card verification and ATM transactionprocessing. This contention technique allows VSATs to transmit at anytime, and to continue transmitting if they receive acknowledgement thatno other station is sending. However, this method requires that channelutilization be held to around 18 to 36 percent.

Other systems use a slot reservation access mode, wherein the hostreserves slots for each user to transmit an assigned number of packets.In assigning bandwidth to match an assigned message duration, moreefficient use of bandwidth is made than with the random access method,thus improving throughput. A drawback to this method is that more timeis required for channel setup, adding further delay, and there may betoo few or too many packets assigned for message transmission for eachuser, leading to at least some inefficiency in bandwidth utilization.Further, dynamic reallocation of bandwidth is not efficientlyaccomplished using this approach.

Even if an ALOHA-type of channel access scheme is successfully used togain access to bandwidth for uplink, there is still the problem ofeither over or under-loading the return channels, and also of having animbalance between groups of return channels.

What is needed, therefore, is an apparatus and method for dynamicallyassigning uplink bandwidth depending on the users' demands for returnchannel access. What is further needed is an apparatus and method forbalancing the uplink loads between return channels sharing a commonuplink channel grouping, and which also balances the system load betweengroups of uplink channels which share common frame timing.

SUMMARY OF THE INVENTION

The present invention solves the aforementioned problems of providing asystem, apparatus, and method for assigning uplink bandwidth dependingon the user's demand for return channel access, and to ensure that aload-balanced condition between and among return channel groups ismaintained.

In one aspect of the invention, a control station for two-way satellitecommunication includes an RF section for transmitting a broadcast signaland receiving a return channel from a remoter user. A return channelsubsystem includes a return channel controller to process return channelinformation and set a user bandwidth in the return channel. The returnchannel controller sets the transmit frequency and bandwidth of thereturn channel by evaluating either or both of a user backlog indicatorand a bandwidth allocation request provided by the remote user in one ormore return channel messages. The return channel controller also changesthe return channel frequency within a return channel group based ontraffic loading within the return channel group.

In a second aspect of the invention, a transceiver is used to transmit aframe synchronized message to a control node, and includes a receiverwhich detects a control node timing message in a received broadcastsignal. A timing recovery section uses the control node timing messageto determine a system-wide transmit frame start time, and a messagebuffer temporarily stores an outgoing user message until it istransmitted. A transmitter uplinks the outgoing user message during anassigned period after the transmit frame start time using an assignedtransmit frequency determined by a group status message received in thebroadcast signal. If necessary to achieve load balance, the transmitfrequency can be changed to a different transmit frequency within acurrent channel group, or changed to a frequency within a differentchannel group, depending on the relative loading of the two returnchannel groups, and the remote user's bandwidth requirement, as reportedin the group status message received from the broadcast signal. Theability to assign transmission to another frequency in a differentreturn channel group results, at least in part, by sharing a commonsystem frame timing among all return channel groups.

In a third aspect of the invention, a method for controlling a returnchannel from a control station includes transmitting a broadcast signal,receiving a return channel uplink from a remote user, and setting areturn channel bandwidth and frequency with a return channel controllerwhich provides an allocation message in the broadcast signal for receiptby the remote users. The return channel bandwidth and frequency are setby evaluating a backlog indicator provided by the remote user, and byevaluating the relative loads of all the return channel groups andindividual transmit frequencies within the return channel groups.

In a fourth aspect of the invention, a method for transmitting a framesynchronized message from a remote user includes receiving a controlnode timing message in a broadcast signal, determining a return channelframe start time using the control node timing message, temporarilystoring an outgoing user message, and transmitting the outgoing usermessage on a transmit frequency during an assigned period after thereturn channel frame start time. The transmit frequency and assignedbandwidth may be determined by an inroute assignment message received inthe broadcast signal. The remote user may initially transmit on a returnchannel configured to support an ALOHA-burst signal. This burst signalincludes an indication of the remote user's message traffic backlog tothe control node. The remote user may then be moved to a return channelwhich either shares access with another remote user, or which providesdedicated uplink access, depending on available system resources and theremote user's bandwidth requirement. The initial ALOHA-burst uplink issent on a transmit frequency selected locally by the remote user using arandomly weighted frequency selection process based on the system orgroup load reported over the broadcast signal.

In a fifth aspect of the invention, a communication system for balancingtraffic on a plurality of return channels includes a control station totransmit a broadcast signal to a remote user. The broadcast signalincludes a non real-time frame marker, a timing message, and a returnchannel control message. A receiver at the remote user receives thebroadcast signal and determines a return channel frame start time usingthe non real-time frame marker and the timing message. A transmitter atthe remote user uplinks a user message on one of the return channelsduring a predetermined period after the return channel frame start time.An uplink frequency and bandwidth of the return channel is determined bythe return channel control message so as to account for system andreturn channel group loading, and to account for user message backlogs.An initial transmission from the remote user may be made using anALOHA-type burst signal that provides a message backlog indication. Thisinitial transmission may be made on a frequency determined from arandomly weighted, load-based frequency selection process in order toensure dynamic balance between return channel groups.

In a sixth aspect of the invention, a method for balancing loads amongand between groups of return channels in a communication system includesrequesting return channel bandwidth in an uplink message from a remoteuser to a control station. The uplink message may include a backlogindicator and a bandwidth allocation request. A return channel bandwidthfor the remote user may be allocated by processing the backlog indicatorand a channel allocation message provided from the control station tothe remote user in the broadcast signal. The channel allocation messagemay also allocate the return channel bandwidth. A user message istransmitted on a return channel in accordance with the channelallocation message.

The present invention in all its embodiments, collectively andindividually, has a number of features that distinguish it overconventional bandwidth allocation schemes. For instance, the presentinvention dynamically assigns bandwidth based on how much the usersactually need, and directs uplink frequency changes to balance trafficload. The approach of the apparatus, system and method of the presentinvention not only balances the load between return channel groups, butwithin each return channel group as well, ensuring an optimizedbandwidth allocation scheme. The system is set up to automatically loadbalance every time a remote user starts a new uplink session, andaccomplishes the goal of having roughly the same number of uplink userssharing each inroute channel, even with a large and increasing number ofsystem users. This approach is particularly well-suited and optimizedfor TCP/IP satellite traffic, and is a highly desirable component tooperating an efficient TCP/IP system over a TDMA-based satellite system,including multiple satellites networked with the required supportingground infrastructure.

Finally, the method and system of the present invention allow expansionto an essentially unlimited number of users on the same return channelswithout extensive hardware and software modifications, and allows theseusers to all have approximately equal access to the return channelcapacity, or bandwidth. This capability is brought about, at least inpart, by sharing system frame timing among all return channel groups,regardless of the broadcast source of the return channel controlinformation sent from the control station, possibly includingmulti-satellite links. The system preferably shares a common non-realtime reference provided to all remote users, regardless of theparticular broadcast being received, or its source.

These and other features and advantages of the present application willbecome more readily apparent from the detailed description givenhereinafter. However, it should be understood that the detaileddescription and specific examples, while indicating a preferredembodiment of the invention, are given by way of illustration only,since various changes and modifications within the spirit and scope ofthe invention provided by this detailed description will become apparentto those skilled in the art.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and advantages of the invention will be more readilyunderstood upon consideration of the following detailed description ofthe invention, taken in conjunction with the accompanying drawings inwhich:

FIG. 1 depicts a conventional satellite communication system;

FIG. 2 shows the two-way satellite communication system of the presentinvention;

FIG. 3 shows the preferred IP/DVB protocol layering used in the presentinvention;

FIG. 4 provides a block diagram of a preferred return channeltransceiver; and

FIG. 5 provides a diagram of the NOC return channel subsystem interface.

DETAILED DESCRIPTION OF THE INVENTION

A preferred embodiment of the method and system of providing returnchannel TDMA frequency and bandwidth allocation of the present inventionis described below. Although described generally in terms of HughesNetwork Systems' Two-Way DirecPC® for ease of discussion, the thrust ofthe communication bandwidth allocation system, apparatus, and method ofthe present invention could be embodied in other forms with only slightvariations as to the detailed implementation. It also will be obvious toskilled artisans in the relevant art that all features of the inventionwill not be described or shown in detail for the sake of brevity andclarity.

The present invention is designed to control allocation of the availablebandwidth of groups of return channels that share the same uplink frametiming derived across multiple transport streams. For simplicity, thistwo-way satellite communication system 200 is characterized in FIG. 2 asincluding one or more Network Operations Center (NOC) 210 (also commonlyknown as a “hub”, “outroute”, “control node”, “control station”, or“earth station”, etc.), at least one satellite 230 having uplink anddownlink transponders, one or more (i.e., 1 to k) remote users 240, eachat a user node and having a satellite receive and transmit capabilityprovided by an associated transceiver 250, which provides an integrateduplink (or “return channel”) capability. Transceiver 250 may transmit onone of a plurality (i.e. “n”) of return channel groups 260, which, forexample, may each have “m” channels or frequencies available for uplink.

Thus, compared to conventional transceiver 150 in FIG. 1, transceiver250 potentially has more uplink frequencies available, that is, “m×n”frequencies instead of only “m”, due to the ability of two-way satellitecommunication system 200 to access any of the return channel groups 260,and the limitation of conventional transceiver 150 to only the “m”channels available on its assigned return channel group.

FIG. 2 also illustrates two NOCs 210, i.e. NOC1 210 a and NOC2 210 b,which each provide at least one DVB Transport Stream 220 (e.g. 220 a and220 b) to satellite 230 for further retransmission. The DVB transportstream retransmitted from satellite 230 is shown merely as DVB transportstream 220 for clarity. Each NOC 210 in the system of the presentinvention may provide support for several receive or outroute channels.System symbol timing reference 270 preferably provides common symboltiming to each NOC 210 in the system, so that timing information usedfor deriving uplink frame start times may be recovered by all remoteusers 240. NOC 210 also preferably provides access to the internet or anintranet through gateway 170.

However, application of the method and system of the present inventionis not intended to be limited to a system having a specific number ofNOCs 210 or remote users 240. Further, NOC 210 in FIG. 2 isdistinguished from NOC 110 in FIG. 1 by each NOC 210 having the abilityto support receiving and processing return channel traffic from remoteusers 240 which is transmitted in accordance with a common system timingscheme.

A receive channel in transceiver 250 could, for example, operate at arate of 48 Mbps, and the transmit channel in transceiver 250 ispreferably a VSAT-like TDMA channel. Depending on consumer requirements,the channel rates for the transmit, “return, or “inroute” channel couldbe, for example, 64 kbps, 128 kbps, 256 kbps, or possibly even higher,as consumer needs arise. A group of multiple transmit channels may alsobe shared among several independent DVB transport streams 220, whethertransmitted from the same or different NOC 210. The return channel alsopreferably contains a link-layer protocol, at the burst level, toprovide for a substantially lossless channel.

The receive channel in transceiver 250 receives a DVB transport stream220 from NOC 210 which preferably uses an IP packet format which mayinclude packets arranged in accordance with the MultiprotocolEncapsulation (MPE) standard. A preferred superframe message 300 isdepicted in FIG. 3, wherein a superframe marker is periodicallytransmitted. However, the superframe marker may be transmitted onlyevery integral number of frames, such as every eight frames, forexample. The stream preferably has DVB compliant MPEG-2 formatting whichsupports multiple MPE messages in a single MPEG frame. The transportstream may include fixed-size 204 byte MPEG packets, which could contain188 bytes of user traffic and 16 bytes of forward error correction (FEC)data, for example.

Preferably, an MPE header may also include specific media access control(MAC) data fields to indicate the type of media or traffic contained inthe data stream, e.g., superframe numbering packet (SFNP), unicast,multicast, conditional access, return channel messages, or returnchannel group messages, and other data fields to indicate, for example,whether the packet is encrypted. Forward error correction (FEC) atvarious rates may also be supported, e.g. FEC rates of 1/2, 2/3, 3/4,5/6, or 7/8. Further, the header of each frame may also contain a PacketIdentifier (PID) to distinguish between elementary streams in the DVBtransport stream 220 so that remote user 240 may filter the message byPID. For ease of discussion, DVB transport stream 220 will be referredto hereinafter simply as “broadcast”.

As for the main thrust of the present invention, allocation of bandwidthand frequencies to the return channels as well as system monitoring andcontrol functions may be carried out by use of a series of messagescontained in various bytes of the broadcast stream transmitted to remoteusers 240.

For example, the DVB MPE protocol layer preferably provides for MACfields which support various user MAC addresses as discussed above. Inparticular, return channel messages preferably include inroutecommand/acknowledgement packet (ICAP) messages and inroute groupdefinition packets (IGDP). Return channel group messages preferablysupport bandwidth allocation packets (BAP), inroute acknowledgementpackets (IAP), and ICAP packet messages. These packets may all use UserDatagram Protocol (UDP) datagrams, which utilize a transport protocolsupported by the TCP/IP protocol architecture, and which support aconnectionless transport service for unicast and multicast transmissionsbetween UDP endpoints. Each of these message packets is discussed infurther detail below, and in the tables provided.

Turning to FIG. 4, transceiver 250 preferably supports TCP/IPapplications, e.g. web browsing, electronic mail and FTP, and alsomultimedia broadcast and multicast applications using IP Multicast, e.g.MPEG-1 and MPEG-2 digital video, digital audio and file broadcast.Transceiver 250 provides a high-speed, over-the-air return channel as analternative to a low-speed terrestrial return channel. Transceiver 250contains receiver (RCVR) 410, processor 420, RF transmitter (RF XMTR)430, timing recovery section 440, and Transmit Unit (TU) 450. RF XMTR430 modulates and transmits, preferably in burst mode, the in-boundcarrier to satellite 230 and NOC 210. RF XMTR 430 may operate with, andbe controlled by TU 450 and RCVR 410 via processor 420, which also couldmaster RCVR 410 by use, for example, of a universal serial bus (USB)adapter (not shown). Configuration parameters and inbound data fromprocessor 420 may be input to RF XMTR 430 through a serial port (notshown), and transmitter status information from RF XMTR 430 may also beprovided through the serial port to processor 420. TU 450 conditions theoutgoing data signal by incorporating the appropriate signal protocolsand modulation scheme, e.g. IP/DVB protocol and TDMA using QPSKtechniques, including Offset-QPSK (OQPSK).

RCVR 410 receives broadcast 220 from satellite 230 through antennasection 460, and recovers and provides appropriate timing-relatedsignals to timing recovery section 440. Timing recovery section 440corrects or compensates the time of receipt of the received frame markerin accordance with timing information contained in the receivedbroadcast signal, for example, in a SFNP. Timing recovery section 440further enables RF XMTR 430 through processor 420 and TU 450 to transmitat the appropriate time in accordance with a TDMA time-slot allocationscheme. Finally, antenna (ANT) 460 propagates and receives signalsto/from satellite 230.

A discussion of the nature, approach and operation of the bandwidth andfrequency allocation system and method of the present invention follows.FIG. 5 shows some of the interfaces within NOC 210. Return channelsubsystem (RCS) 510 in NOC 210 interfaces with NOC signal distributionsection 540, NOC timing section 550, and NOC processor 560. Among otherfunctions, RCS 510 reassembles packets received from remote users 240over the return channels and a NOC inroute receiver (not shown) into IPpackets for further processing. Non real-time frame timing transmittedin the broadcast stream to remote users 240, and ultimately used foruplink timing in the return channels, is derived from a pulse fromreturn channel controller 520 in RCS 510. Return channel controller 520also allocates bandwidth, coordinates the aperture configuration, andsends framing pulses to burst channel demodulators (BCD) 530. The numberof BCDs 530 supported by RCS 510 is preferably at least 32 arranged toallow redundant equipment support for at least 28 return channels.Multiple sets of return channel subsystems 510 may be provided in anetworked cluster arrangement (not shown) within each NOC 210 to allowfor processing of a large number of return channels, preferably up to100,000 or more, for example. Return channel traffic from the remoteusers provided from the NOC RF section (not shown) and the NOC inroutereceiver (also not shown) and routed through NOC signal distributionsection 540 is applied to one or more BCD 530 to demodulate returnchannel data received from the remote users, as directed by returnchannel controller 520.

In addition, return channel controller 520 provides framing pulses toNOC timing section 550. NOC timing section 550 preferably includesappropriate means (not shown) to measure and compare packet delaysassociated with both internal NOC delays and NOC-satellite delays,respectively. NOC timing section 550 also preferably functions as a“delay tracker” to ascertain and update the aforementioned delays. Thesedelays may be determined from signals provided both from internal systemtiming signals and the broadcast signal as “echoed” or received fromsatellite 230.

NOC timing section 550 provides the appropriate frame timing informationto NOC multiplexer section (NOC MUX) 570 through NOC processor 560. NOCMUX 570 combines broadcast data intended for the remote users 240 withframe timing information from NOC timing section 550, and provides apacketized data signal to NOC signal distribution section 540 fortransmission to satellite 230 through the NOC RF section (not shown),and ultimately to remote users 240. Remote users 240 use the broadcastframe timing information to derive their own uplink frame start timewhich is preferably synchronized throughout two-way satellitecommunication system 200.

The equipment, signals, and subsystems within each of NOC 210 andtransceiver 250 are preferably interconnected via one or more local areanetworks (LAN) (not shown) and, even more preferably, are interconnectedin accordance with an open system architecture approach which allowsmodifications and upgrades to be more easily accomplished asimprovements in software and hardware become available or desirable.

The underlying timing approach of the present invention which allowsbandwidth and frequency allocation to take place across a large numberof return channels on different return channel groups is to provideinformation to RCVR 410 so that transceiver 250 may precisely time itsburst transmission time as an offset of the received superframe header.The superframe header received in a superframe numbering packet (SFNP)transmitted in the broadcast is used by every remote user 240 tosynchronize their transmit start of frame marker to the superframemarker pulse generated by return channel controller 520. This superframenumbering packet (SFNP) is used to lock network timing for the returnchannels, and as a beacon to identify which network is being connectedto. This packet is transmitted on the “Superframe Number Packet” MACaddress (see Table 1). However, receipt of the SFNP by itself is notsufficient because there are delays from the time that return channelcontroller 520 generates the superframe header until the time receiver410 actually receives the SFNP.

Further correction is applied by receiver 410 to account for theinternal NOC outroute delay, a NOC-satellite transmission time delay,and a transmission delay from the satellite to each of the specificremote users 240, preferably based on known parameters determined duringa standard satellite-user “ranging” process during systeminitialization, and on additional timing information provided from NOC210 in broadcast 220.

Thus, once every superframe, an internal NOC delay between the time theprevious superframe header was supposed to have been sent, and the timethat it actually was sent is broadcast in a SFNP message to all remoteusers 240. This value, along with a “space timing offset” (STO) relatedto the transmission delays from NOC 210 to remote user 240, is used byeach remote user 240 to calculate the actual start time of thesuperframe. Remote user 240 uses the calculated superframe start time asthe TDMA uplink frame time reference point for determining an upcomingtransmit frame start time. Preferably, the internal NOC delay isroutinely updated by NOC Timing section 550, and is thereafter alsobroadcast in a subsequent SFNP message to remote users 240.

Knowing the synchronized uplink frame start time, and preferably sharingthe same uplink frame start time among all remote users 240, allows NOC210 to efficiently control bandwidth allocation and frequencyassignments among all remote users 240, both between and within allreturn channel groups 260.

The operation of the communication timing system of the presentinvention will now be described. NOC 210 takes formatted data packetsand transmits them on the DVB transport stream 220 to satellite 230 forfurther retransmission to remote users 240. The data stream or “payload”information is transmitted following an appropriately formatted MPEheader and initialization vector, if the packets are encrypted.

Included in the DVB transport stream 220 is the SFNP which provides asuperframe marker, as well as the internal NOC delay and satellite driftcorrection for a previous superframe marker transmitted in a prior SFNP.

When remote user 240 receives a SFNP at their respective RCVR 410, thereceived superframe packet is adjusted by timing recovery section 440 atremote user 240 to determine its upcoming uplink transmission time suchthat the transmitted or uplink frame is received at the proper time atNOC 210. The time at which the site preferably must transmit is asatellite hop before the time that NOC 210 expects the data to bereceived. The transmission time may be measured by starting at a timelater than the regenerated superframe time by the STO. The NOC delay andthe receiver-satellite delay are subtracted from this timebase. A finaladjustment to account for satellite drift is then made. Then, knowingthe fixed frame length, e.g. 45 ms, the frame start time of a subsequentuplink transmit frame can be determined.

Once the frame timing is determined, a nominal value, e.g. close to 45ms, will preferably be used on a continuing basis with minor adjustmentsto account for drifts between the counter and the timing pulse. Once TU450 is aligned, there are only small corrections necessary to keep TU450 synchronized to NOC 210.

Initially, if remote user 240 needs to uplink message traffic, access ispreferably requested on one of a pre-designated set of ALOHA burstchannels. Remote user 240 preferably has different states wherein it mayor may not be able to transmit messages. The states of receiver 410 intransceiver 250 may include:

-   -   1) Acquisition: Receiver 410 acquires broadcast 220. During this        time, transceiver 250 is unable to transmit, and uses the SFNP        for acquisition.    -   2) Learning Mode: Receiver 410 learns about the available return        channel groups by receiving the IGDP messages (see Table 2).        Remote user 240 will only use a return channel if its TU 450 and        RF XMTR 430 are available.    -   3) Ranging: If the remote user 240 has not set up its timing        from its current location, it will request a ranging session        from NOC 210 by sending a ranging request via a ranging burst. A        closed-loop process is used to fine tune timing and power.    -   4) Request Bandwidth: Once the site has been ranged and data is        to be transmitted, an ALOHA burst is used to transmit the data.        A backlog indicator will be used to trigger NOC 210 to allocate        bandwidth.    -   5) Send Traffic: Remote user 240 sends user traffic via an        allocated return channel in one of return channel groups 260        using allocated “stream” bandwidth, i.e. bandwidth which        essentially dedicates the entire TDMA transmit frame to remote        user 240.

The IGDP packet (see Table 2) is preferably used to define the returnchannels in a return channel group 260 and their availability, and toallow selection of return channel groups for user traffic (using ALOHAfor the setup) and ranging. Return channel groups may also be used toallow for load sharing between a number of return channels, and tominimize NOC 210 outroute bandwidth required to control the returnchannel bandwidth allocation. Return channel groups preferably limit theamount of information that needs to be cached or processed by receiver410. The IGDP is preferably sent on the return channel broadcast MACaddress.

The IGDP preferably uses one packet per return channel group persuperframe, for example, 26 kbps of bandwidth for 75 return channels pergroup, and 300 return channels. It may also be transmitted on an “AllRCVR” Multicast address.

Each receiver 410 preferably monitors all IGDPs. Receiver 410 preferablyfilters out return channel types that it is not configured to support,and may time out the definition if not received for three superframetimes. An inroute group table is preferably created in each receiver 410from information contained in all of these packets. This table ispreferably almost static in order to minimize the overhead processing inprocessor 420 required to reorganize its inroute group table. Minimizingtable changes is desirable to reduce potential disruptions to system 200operations. When remote user 250 is active, i.e. has bandwidth, itpreferably monitors its currently assigned inroute group, as well as asecond inroute group near the time it is moved between inroute groups.

In order to limit latency when any of remote users 240 need to transmit,all inactive transceivers 250 with valid ranging information may make arandom weighted selection, e.g. every 4th frame time (in thesuperframe), between all the inroute groups that advertise a non-zeroALOHA Metric. Remote user 240 will preferably start to monitor thatinroute group, and the previous inroute group will also preferably bemonitored until all previous BAPs have been received, or lost. By makingsuch a random weighted selection, the possibility of suddenly making alightly-loaded uplink channel heavily loaded is reduced if multipleremote users 240 should need uplink access at roughly the same time.

First, transceiver 240 may randomly select two of the ALOHA channelsover the next configured number of frames for the inroute group it hasselected. A reasonable assumption is that the ALOHA burst configurationis generally static over time, and that the ALOHA burst channel will beavailable. When remote user 240 needs to go active, and has nooutstanding ALOHA packets, it may pick a random number of frames.Ignoring any frame times that had no bandwidth available from above,transceiver 250 preferably transmits a single burst during the randomlyselected frame time, and waits to be acknowledged. If it is notacknowledged, or the acknowledgement is lost, it may repeat the sendingof the ALOHA packet up to a number of retries indicated in the SFNP,using a so-called “diversity ALOHA” approach.

The ICAP packet (see Table 3) may be used along with the DVB MPEprotocol MAC addressing scheme for, among other reasons, explicitlyacknowledging ALOHA bursts by using acknowledgement packets sentpreferably, for example, on an inroute group's multicast address, toreduce NOC 210 outroute bandwidth. Tables 3a through 3d provide avariety of message acknowledgement types which are preferably supportedby the system and method of the present invention.

While the ALOHA packet is outstanding, i.e. awaiting acknowledgement,transceiver 250 preferably monitors up to three inroute groups, i.e. onefor an ALOHA Acknowledgement, one for a new inroute group to try, andone for the previously assigned inroute group, for example, in case alate acknowledgement or other message type is transmitted late on thepreviously assigned inroute group.

After receipt of an acknowledgement, the bandwidth allocation packet(BAP) is preferably used to define the current bandwidth allocation forall inroutes associated with an inroute group. Each frame, receiver 410may receive another BAP from the inroute group on which it is currentlyexpecting to receive bandwidth. In order to be able to transmit data andprocess acknowledgements, receiver 410 may need to scan the entireinroute group table to derive the following fields it may need:

-   -   1) Inroute Group—Since receiver 410 can be monitoring 2 inroute        groups, it will preferably confirm the inroute group based on        the MAC address of the packet, and only process the BAP for        which it expects to use bandwidth.    -   2) Inroute Index—This is the cumulative burst offset per slot        size of a frame, and may be used as an index into the frequency        table of the IGDP.    -   3) Frame Number—This field may come directly from the frame        number field of the packet.    -   4) Burst Id—This may be the 4 least significant bits of an index        into the Burst Allocation Table in the BAP (see Table 4).    -   5) Burst Offset—The Cumulative Burst Offset preferably starts at        0, and increases with the each burst size. The Burst Offset is        preferably the Cumulative Burst Offset MOD Slot Size of a frame        (i.e., modulus division).    -   6) Burst Size—This field may come directly from the Burst        Allocation Table, and will preferably never cross a frame        boundary.    -   7) Acknowledgement Offset—This is the Index into the Burst        Allocation Table of the entry.

Preferably, the IDGP may use one packet per inroute group per frame, or535 kbps of bandwidth for 25 active users per inroute, 75 inroutes pergroup, and 300 inroutes, for example. Since it is preferably transmittedon the inroute group's multicast address, each receiver 410 will onlyhave to process 134 kbps. To attempt to ensure that active users do nothave performance impacted, or data lost by any load balancing at areturn channel subsystem 510, observation of the following rules byremote user 240 is desirable:

-   -   1) At least five frames prior to moving remote user 240 to a        different inroute group, but on the same return channel        subsystem 510, remote user 240 must be notified, so that it can        begin to monitor both inroute group streams, and will need to        continue monitoring both streams until all outstanding inroute        acknowledgement packets (IAP) are received, or have been lost.        See below and Table 5 for a description of IAP.    -   2) There should be at least one frame time having no bandwidth        allocated between bursts that are assigned to different        inroutes. This is to ensure that remote user 240 will be able to        fill all it's assigned slots, and still have at least one frame        time for tuning to the new frequency. This requirement        preferably applies to bursts that are defined across consecutive        BAPs, and when moving between inroute groups on the same RCS        510.    -   3) There preferably should be at least one complete frame with        no bandwidth allocated between normal and ranging bursts. This        is to ensure that transceiver 250 will be able to fill all it's        assigned slots, and still have at least one frame time for        tuning and adjusting transmission parameters.    -   4) After the BAP that moves remote user 240 to a different        inroute group is sent, RCS 510 will continue to receive bursts        under the old inroute group for a time in excess of the round        trip delay. RCS 510 preferably accepts and acknowledges these        frames, and remote user 240 should continue to monitor        acknowledgements from the old inroute group.    -   5) Remote user 240 should not have its bandwidth moved to a        different inroute group while it is still monitoring a previous        inroute group it has just been moved from.    -   6) Transceiver 250 will preferably only be assigned multiple        bursts during a single frame time if they are all on the same        inroute, and are all back to back in the frame, but without the        burst overhead of turning RF XMTR 430 on and off for each        packet.    -   7) All of the bursts, except the last, preferably are large        enough for the maximum sized packet (largest multiple of the        slot size ≦256, for example), but only the first will have burst        overhead / aperture included in it's size.    -   8) Once an AssignID (see Tables 3a-3d) is assigned to a        transceiver 250 on an inroute group, it will not change while        the transceiver remains active, except as part of being moved        between inroute groups.    -   9) Once an AssignID is assigned to a transceiver 250 on an        inroute group, it preferably should be left fallow for five        superframe times after it is no longer in use.

The inroute acknowledgement packet (IAP) in Table 5 is preferably usedto explicitly acknowledge each inroute packet for assigned bandwidthwith a valid cyclic redundancy code (CRC), regardless of the presence ofany encapsulation data, to allow for faster recovery of inroute packeterrors. ALOHA and non-allocated ranging packets are acknowledgedexplicitly (see Table 5). The IAP preferably uses one packet per inroutegroup per frame, or approximately 57 kbps of bandwidth for 25 ActiveUsers per inroute, 75 inroutes per group, and 300 inroutes, for example.Since the IAP is preferably transmitted on the inroute group's multicastaddress, each receiver 410 will only have to process approximately 15kbps. If the IAP is lost, the transceiver 250 may automaticallyretransmit the packet. The loss of the IAP for a particular inroutegroup could be detected by the next IAP packet received, or if no IAP isreceived for four frame times, for example.

As for return channel message transmissions, the burst data frame hasspecific structures for ALOHA bursts (i.e. non-allocated bandwidth), andwhen bandwidth is allocated. Examples of the different types of packetheaders preferably used for these two data frame structures are providedin Tables 6 and 7, respectively. Two different header structures can beused to maximize efficiency of the allocated bandwidth messages, byminimizing the size of required message headers. RCS 510 can detect thetype of burst from the frame numbering information in the packet header.

The inroute packet format may consist of a variable size header and 0 ormore bytes of encapsulated datagrams. The encapsulated datagrams aresent as a continuous byte stream of concatenated datagrams, preferablywith no relationship to inroute packetization. Proper interpretationrequires reliable, in-order processing of all data bytes, preferablyonly once. To resolve problems due to data loss on the inroute, aselective acknowledgement, sliding window protocol may be used. As isthe case for such sliding window protocols, the sequence number spaceshould be at least twice the window size, and data outside the window isdropped by the receiver.

For allocated streams, i.e. where bandwidth has been allocated to aremote user 240 (see Table 7), inroute burst data will preferably beretransmitted if not acknowledged in the IAP for that frame number, orif that acknowledgement is lost. If synchronization problems occur, RCS510 can force transceiver 250 to be inactive by removing its bandwidthallocation. This preferably causes transceiver 250 to reset its sequencenumber and datagram counter to 0, and start at the beginning of a newdatagram. Since the sequence number is preferably reset every timetransceiver 250 goes active, any data sent in ALOHA or non-allocatedranging bursts may be duplicated due to retransmissions, if theacknowledgement is lost, and also due to diversity Aloha, discussedpreviously.

When back to back bursts are allocated to the same transceiver 250, itpreferably does not turn off the unit, and will use the saved overheadassociated with burst processing to deliver extra “payload”, or usermessage traffic. This will help maintain a desired 1 to 1 mapping ofallocated bursts to packets.

In the system, apparatus and method of the present invention, and with apreferred remote user and return channel addressing scheme, there isessentially no limitation on the number (“k”) of remote users 240 whichmay uplink data on a return channel. A minimum of 2²⁴ (˜16 million)transceivers are preferably supported by the addressing scheme embodiedwithin the DVB stream and, even more preferably, up to 2²⁸ (˜256million) transceivers are supported.

Further, because the return channel is preferably a substantiallylossless channel, compression techniques may effectively be employed toreduce bandwidth requirements. IP header compression has the potentialto give a tremendous improvement in bandwidth, since such compressioneliminates 10-15 bytes for every IP packet.

While a preferred embodiment has been described above in terms of a TDMAbandwidth or slot allocation approach, this preferred embodiment is inno way to be considered limiting, and is provided only by way ofexample. As a further example, the method and system of providingbandwidth and frequency allocations can be accomplished across any typeof communication system having multiple users sharing the same media,and may find particular application in any slotted-time system thatrequires bit timing, e.g. a frequency-time system using a phase-lockedloop (PLL) or frequency-locked loop (FLL) based upon the same timingstandard. In addition, although the present invention provides benefitsto using TCP/IP applications, the system, apparatus and method of thepresent invention is not limited to this choice of protocols.

It will be obvious that the present invention may be varied in manyways. Such variations are not to be regarded as a departure from thespirit and scope of the invention, and all such modifications as wouldbe obvious to one skilled in the art are intended to be included withinthe scope of the following claims. The breadth and scope of the presentinvention is therefore limited only by the scope of the appended claimsand their equivalents. TABLE 1 Superframe Numbering Packet (SFNP) FormatBits Field Description/Notes  8 Frame Type A value of 1 indicates a SFNP(Super Frame Numbering Packet)  1 Timing Source Used to distinguishwhich timing unit generated this SFNP. 32 SFNP Interval This resultindicates the elapsed time between this Super Frame pulse and theprevious pulse and allows RCVR 410 to adjust for any differences betweenit's local measurement clock and a clock used by NOC timing units. If aclock used by NOC timing units has high accuracy, RCVR 410 will onlyneed to receive 3 consecutive SFNP to be able to interpret this field.32 SpaceTimingOffset (STO) This is approximately the number of msecbetween an outroute superframe pulse and the time that the first framefrom the superframe will be received at the NOC.  4 Aloha Backoff Thisis the number of frames (minus one) for an initial random backoff forthe ALOHA transmission.  4 Aloha Retries This is the number of times(minus one) that a packet retransmission is attempted using the initialrandom backoff before Processor 420 may abort transmission. 16 Aloha MaxAfter the Aloha Retries have been exceeded, the Backoff transmission maybe aborted, but RCVR 410 may continue to attempt to recover in thebackground.

TABLE 2 Inroute Group Definition Packet (IGDP) Format Bits FieldDescription/Notes  8 Frame Type A value of 2 indicates an inroute groupDefinition Packet  7 Inroute Identifier for each inroute group. Thismust be unique across Group ID all inroute groups that are available toa set of NOC Outroutes.  5 Frequency This field is the offset into thepacket (in 16 bit words) of a Offset Frequency Table (not shown).  4Return Indicates the type of Return channels that are defined in thischannel Type group. Example values for OQPSK with Convolutional Encodingare: (0-64 kbps, 1-128k, 2-256k) 16 Bandwidth This metric is used forrandom weighted selection of a Return Metric channel Group when goingactive. It may be based on a ratio of the number of return channelsavailable for user traffic to the active number of users, and may alsobe used to ensure that users are evenly distributed between inroutegroups. A value of zero indicates an unavailable inroute group, or noALOHA defined for this group. N × 24 Frequency This is the Frequencyused to transmit on each of the Return Table channels in the Group.Changing the Frequency for a Return channel should be carefullycoordinated to avoid interruptions of network operation, or transmissionon the wrong Return channel frequency around the switch over point.There could be, for example, an upper bound of no more than 4,000 returnchannels between all Return channel Groups for an Outroute. The upperbound for the number of return channels in each Return channel Group,could be based on a limit of the number of Burst Allocations in theBandwidth Allocation Packet (BAP). The value of N may be derived fromthe length of the IP Datagram. If an inroute is not used, then itsbandwidth will be allocated to a reserved AssignID from the BAP. Thefrequency may be encoded as: Frequency = 14 GHz + value × 100 Hz.

TABLE 3 Inroute Command/Acknowledgement Packet (ICAP) Bits FieldDescription/Notes  8 Frame Type A value of 5 indicates an InrouteCommand/ Acknowledgement Packet  5 Number of This is the number ofentries in the Offset Table. Entries 16 Frame Number ForAcknowledgments, this is the Frame Number that is being acknowledged.For Commands, this is the Frame Number the Command will take effect on.N × 10 Offset Table This is a table of offsets wherein each of thevariable sized Command/Acknowledgment fields begin. The size should beknown based on the Command field, but can also be derived from theOffset for the next Entry, or from the size of an IP datagram for thelast entry. Each offset may be a 10-bit value, and starts from thebeginning of the Offset Table. The value of N is the Number of Entries.N × 8  Command/ This is a list of Commands or Acknowledgments definedAcknowledgment in Tables 3a-3d. No more than 1 Command or Acknowledgmentcan preferably be sent per Packet. A value of N may be derived from theIP Datagram length.

TABLE 3a Aloha Acknowledgement Bits Field Description/Notes 26 SerNrThis is the Serial Number of RCVR 410, for example, or other uniqueremote user identifier.  5 Command A value of 1 indicates an AlohaAcknowledgment; only one diversity aloha packet will preferably beacknowledged on the inroute group's multicast address.  7 Inroute GroupID The inroute group, where future bandwidth will be allocated to remoteuser 240. The Inroute Type for this group should be the same type thatwas used in the Aloha packet. 16 AssignID This is an Id that may be usedin future Bandwidth Allocation Packets, where future Bursts will beallocated. A value of 0 could acknowledge the data without assigning anybandwidth.

TABLE 3b Disable/Enable TU Command Bits Field Description/Notes 26 SerNrThis is the Serial Number of RCVR 410, for example, or other uniqueremote user identifier.  5 Command A value of 2 indicates aDisable/Enable TU Command - When disabled, RCVR 410 will not transmitagain until it is explicitly enabled from NOC 210. This setting may bestored in nonvolatile memory in RCVR 410. This command preferably issent on the “All RCVR” multicast address. There may be noacknowledgement to this command.  1 Enable Set to “1” if enable, set to“0” for disable. 16 AssignID This is an Id that may be used in futureBandwidth Allocation Packets, where future Bursts will be allocated.

TABLE 3c Go Active Command Bits Field Description/Notes 26 SerNr This isthe Serial Number of RCVR 410, for example, or other unique remote useridentifier.  5 Command A value of 4 could indicate a “Go Active”Command, for example. RCVR 410 may look for allocated bursts on thespecified inroute group and transmit on the ones allocated to it. Thiscommand is only accepted if RF XMTR 430 is inactive, and has alreadysuccessfully ranged for the Inroute Type. This command is preferablysent on the All RCVR multicast address. This command may also beimplicitly acknowledged by the act of transmitting.  7 Inroute Group IDThis is the inroute group where future bandwidth will be allocated. 16AssignID This is an Id used in future Bandwidth Allocation Packets,where future Bursts will be allocated.

TABLE 3d Change Inroute Group Command Bits Field Description/Notes 26SerNr This is the Serial Number of RCVR 410, for example, or otherunique remote user identifier.  5 Command A value of 5 could indicate aChange inroute group Command - This is only accepted, if remote user 240is active. This command is preferably sent on the inroute group'smulticast address, and is implicitly acknowledged by the act of usingthe new inroute group.  7 Inroute Group ID This is the inroute groupwhere future bandwidth will be allocated. The Inroute Type for thisgroup must be the same type that is currently in use. 16 AssignID Thisis an Id used in future Bandwidth Allocation Packets, where futureBursts will be allocated. A value of 0 can be used to force an RF XMTR430 to go inactive, but the preferred method is to remove it's bandwidthallocation.

TABLE 4 Bandwidth Allocation Packet (BAP) Format Bits FieldDescription/Notes  8 Frame Type A value of 3 indicates a BandwidthAllocation Packet 16 Frame Number This indicates the Frame Number thatis allocated in this packet, and is preferably larger than the currentFrame Number - The difference is a fixed offset to allow transceiver 250sufficient time to respond to changes in allocation. N × 24 BurstAllocation This is preferably a list of all the burst allocations foreach Inroute. It may order all the bursts in a Frame, and then mayrepeat a Frame for each Inroute in the Group. It is preferably limitedto no more than 489 entries, since IP Datagrams are preferably limitedto 1500 bytes. This could be important, as this is a linear search fortransceiver 250. A malformed Burst Allocation Table may degrade of theNetwork, as there preferably is limited error checking on this field.The value of N may be derived from the length of the IP Datagram. SeeTable 4a.

TABLE 4a Burst Allocation Record Format Bits Field Description/Notes 16AssignID This is a unique identifier which may be used to indicate whichremote user 240 the bandwidth was allocated to. The value of 0 may beused to indicate small ALOHA, i.e. bandwidth request and backlogindicator only (and Non- allocated Ranging) bursts, and a value of 1 maybe used to indicate large ALOHA bursts, i.e. backlog indicator and amaximum-sized length message. A value of 0xFFFF may be used to indicatebandwidth that is not assigned. Other values may be dynamicallyassigned, however, there is nothing to preclude RCS 510 from imposingother reserved values, or structure on these values.  1 Ranging Thiscould indicate whether the burst is allocated for normal or Rangingbursts. Preferably, while transceiver 250 is ranging, it will still beable to send encapsulated datagrams over the inroute, and an activeremote user 240 may have ranging turned on/off to test or fine tune itsvalues, with minimal impact on performance.  6 Burst Size Size (inSlots) of this burst, and may include the aperture and Burst Overhead.

TABLE 5 Inroute Acknowledgement Packet (IAP) Bits FieldDescription/Notes  8 Frame Type A value of 4 could indicate an InrouteAcknowledgement Packet 16 Frame Number This may indicate the framenumber for which the acknowledgement applies, and should be less thanthe current Frame Number. N ACK This field is a bitmap that matches theentries for this Frame in the Burst Allocation table of the BAP. Todetermine what was acknowledged, RCVR 410 must determine which burstswere assigned to itself from the BAP, and remember what data wastransmitted during those bursts. The value of N may be derived from thelength of the IP Datagram, and could match the value of N from theassociated BAP.

TABLE 6 Inroute Packet Format (Non-Allocated) Bits FieldDescription/Notes 16 SerNr This is the Serial Number of RCVR 410/XCVR250, for example, or other unique remote user identifier.  1 BacklogThis indicates the presence of the Backlog field. This Indicatorpreferably should always be present for ALOHA and Non- allocated Rangingbursts, unless there is no backlog.  2 Frame Number This is the 2 leastsignificant bits of the frame number, and will help RCS 510 to determinewhich burst was received.  4 BurstNr This indicates which burst slot inthe Frame this was transmitted in, and helps to identify a burst asbeing an ALOHA type burst.  8 Length FEC This is the FEC value for thelength produced via table lookup in software.  8 Length This is thelength of the burst. It includes all the bytes starting with the BacklogIndicator field through the CRC.  8 Backlog This field may be used toindicate the number of bytes of Backlog that are present and ispreferably encoded as a floating point number with a 2 bit exponentfield and a 6 bit mantissa, for example, and may be rounded up by TU450. N × 8 Encapsulated This may contain 0 or more bytes of encapsulatedDatagrams datagrams. There preferably is no relationship between IPDatagram boundaries and the contents of this field, i.e., this field cancontain a section of an IP Datagram, or multiple IP Datagrams. The valueof N can be derived by subtracting the size of the other fields in thepacket from the Length. 16 CRC This is the burst required CRC field. Aburst with an invalid CRC is dropped, and statistics are retained.

TABLE 7 Inroute Packet Format (Allocated) Bits Field Description/Notes16 SerNr This is the Serial Number of RCVR 410/XCVR 250, for example, orother unique remote user identifier.  1 Backlog This indicates thepresence of the Backlog field. Indicator  2 Frame Number This ispreferably the 2 least significant bits of the frame number, and willhelp RCS 510 to determine which burst was received.  4 BurstNr Thisindicates which burst slot in the Frame this was transmitted in. Withthe addition of the Inroute and Frame number it was received on, RCS 510will be able to uniquely identify the source and destination.  8 LengthFEC This is the FEC value for the length produced via table lookup insoftware.  8 Length This is the length of the burst. It includes all thebytes starting with the Backlog Indicator field through the CRC.  8Backlog This field may be used to indicate the number of bytes ofBacklog that are present and is preferably encoded as a floating pointnumber with a 2 bit exponent field and a 6 bit mantissa, for example,and may be rounded up by TU 450. N × 8 Encapsulated This may contain 0or more bytes of encapsulated Datagrams datagrams. There preferably isno relationship between IP Datagram boundaries and the contents of thisfield, i.e. this field can contain a section of an IP Datagram, ormultiple IP Datagrams. The value of N can be derived by subtracting thesize of the other fields in the packet from the Length. 16 CRC This isthe burst required CRC field. A burst with an invalid CRC is dropped,and statistics are retained.

1. A control station for two-way satellite communication, comprising: anRF section for transmitting a broadcast signal and receiving a returnchannel from a remoter user; and a return channel subsystem including areturn channel controller to process return channel information and seta user bandwidth in the return channel.
 2. The control station of claim1, wherein the return channel subsystem further includes a burst channeldemodulator to demodulate the return channel information.
 3. The controlstation of claim 2, wherein the return channel controller controls theburst channel demodulator.
 4. The control station of claim 2, whereinthe return channel controller dedicates the burst channel demodulator tothe remote user based on a bandwidth allocation request provided by thereturn channel information.
 5. The control station of claim 1, whereinthe return channel controller sets the user bandwidth of the returnchannel by evaluating a user backlog indicator provided by the remoteuser in a return channel message.
 6. The control station of claim 5,wherein the return channel message is an ALOHA burst message.
 7. Thecontrol station of claim 6, wherein the ALOHA burst message contains abandwidth allocation request.
 8. The control station of claim 7, whereinthe return channel controller assigns the remote user periodic bandwidthin response to the bandwidth allocation request.
 9. The control stationof claim 6, wherein the ALOHA burst message contains an informationpacket of a predetermined slot size.
 10. The control station of claim 5,wherein the return channel controller allocates bandwidth if the userbacklog indicator is greater than a threshold value.
 11. The controlstation of claim 1, wherein the return channel controller furtherassigns a frequency of the return channel.
 12. The control station ofclaim 11, wherein the return channel controller assigns the frequency ofthe return channel through an inroute assignment packet provided to theremote user through the broadcast signal.
 13. The control station ofclaim 11, wherein the return channel controller changes the frequency ofthe return channel from a first frequency to a second frequency, saidfirst and second frequencies being within a first return channel groupand a second return channel group, respectively.
 14. The control stationof claim 1, wherein the return channel controller changes a frequency ofthe return channel.
 15. The control station of claim 14, wherein thereturn channel controller changes the frequency of the return channelfrom a first frequency to a second frequency, said first and secondfrequencies each being within a same return channel group.
 16. Thecontrol station of claim 1, wherein the broadcast signal is anasynchronous DVB transport stream.
 17. The control station of claim 1,wherein the return channel information is provided by a TDMA signal. 18.The control station of claim 1, wherein the return channel controllerallocates a stream access return channel to the remote user based on abandwidth allocation request provided by the return channel information.19. The control station of claim 18, wherein the return channelcontroller allocates a dedicated frequency to the remote user.
 20. Thecontrol station of claim 18, wherein the return channel controllerchanges an assigned frequency of the remote user.
 21. The controlstation of claim 1, wherein the return channel controller sets the userbandwidth of the return channel by providing a bandwidth allocationpacket to the remote user through the broadcast signal.
 22. The controlstation of claim 1, wherein the return channel controller assigns thefrequency of the return channel by evaluating a user backlog indicatorprovided by the remote user in a return channel message.
 23. The controlstation of claim 1, wherein the RF section receives a plurality ofreturn channels from a plurality of remote users, and wherein saidreturn channel subsystem processes return channel information from theplurality of return channels and sets respective user bandwidths in eachof the plurality of return channels.
 24. The control station of claim23, wherein a subset of the plurality of return channels are configuredto support ALOHA burst transmissions.
 25. The control station of claim23, wherein the return channel subsystem further includes a plurality ofburst channel demodulators each assigned to an associated one of theplurality of return channels to demodulate respective return channelinformation.
 26. The control station of claim 23, wherein the returnchannel controller assigns bandwidth to each of the plurality of returnchannels based upon a predicted traffic load.
 27. The control station ofclaim 23, wherein the return channel controller assigns bandwidth to aportion of the plurality of return channels based upon a predictedtraffic loading, and assigns bandwidth for at least one of the pluralityof return channels based upon a bandwidth allocation request.
 28. Thecontrol station of claim 23, wherein the return channel controllerprovides a load status of a plurality of return channel groups and aload status of the plurality of return channels through an inroute groupdefinition packet provided to the remote user through the broadcastsignal.
 29. A transceiver for transmitting a frame synchronized messageto a control node, comprising: a receiver which detects a control nodetiming message in a received broadcast signal; a timing recovery sectionwhich uses the control node timing message to determine a transmit framestart time; a message buffer to store an outgoing user message; and atransmitter adapted to uplink the outgoing user message on a transmitfrequency during an assigned period after the transmit frame start time,said transmit frequency being determined by a first inroute groupdefinition packet received in the broadcast signal, wherein said firstinroute group definition packet is associated with a first returnchannel group.
 30. The transceiver of claim 29, further comprising aprocessor which provides a traffic backlog indicator included in theoutgoing user message.
 31. The transceiver of claim 29, wherein thetransmit frequency is in the first return channel group.
 32. Thetransceiver of claim 31, wherein the transmit frequency is changed to adifferent transmit frequency in the first return channel group based onthe first inroute group definition packet received in the broadcastsignal.
 33. The transceiver of claim 31, wherein the receiver receives asecond inroute group definition packet in the broadcast signal and thetransmit frequency is changed to a different transmit frequency in asecond return channel group based on the second inroute group definitionpacket.
 34. The transceiver of claim 33, wherein the receiver monitorsboth the first and second inroute group definition packets in thebroadcast signal after uplink bandwidth has been allocated by thecontrol node.
 35. The transceiver of claim 33, wherein the transmitfrequency is changed a predetermined number of frames after the receiverreceives the second inroute group definition packet.
 36. The transceiverof claim 31, wherein the transmit frequency is changed to a differenttransmit frequency in a second return channel group using a randomweighting based on a return channel group load factor.
 37. Thetransceiver of claim 29, wherein the assigned period includes at leastone TDMA slot after the transmit frame start time.
 38. The transceiverof claim 37, wherein the assigned period is determined by a bandwidthallocation packet received in the broadcast signal.
 39. The transceiverof claim 37, wherein the bandwidth allocation packet allocates a streambandwidth wherein an entirety of TDMA slots in a message frame arededicated to the outgoing user message.
 40. The transceiver of claim 29,wherein the assigned period is determined by a predicted traffic loadestablished by the control node.
 41. The transceiver of claim 29,wherein the received broadcast signal is an asynchronous DVB transportstream.
 42. The transceiver of claim 29, wherein the receiver monitors aplurality of inroute group definition packets each corresponding to aspecific one of a plurality of return channel groups.
 43. Thetransceiver of claim 42, wherein the transmit frequency is assigned tobe in the first return channel group based on a group load factorreceived in the broadcast signal.
 44. The transceiver of claim 42,wherein the transmit frequency is changed to be in a different returnchannel group based on a group load factor received in the broadcastsignal.
 45. The transceiver of claim 42, wherein the transmit frequencyis changed to a different group of the plurality of return channelgroups based on a random weighting factor provided in the broadcastsignal.
 46. The transceiver of claim 29, wherein the outgoing usermessage is encrypted.
 47. The transceiver of claim 29, wherein theoutgoing user message is compressed in accordance with a losslesscompression standard.
 48. The transceiver of claim 29, wherein theoutgoing user message is transmitted on a lossless return channel. 49.The transceiver of claim 29, wherein the outgoing user message ismodulated on the transmit frequency using a QPSK modulation scheme. 50.The transceiver of claim 49, wherein the QPSK modulation scheme is anOffset-QPSK (OQPSK) scheme.
 51. The transceiver of claim 29, wherein theoutgoing user message is limited to a maximum bandwidth by the controlnode.
 52. The transceiver of claim 29, wherein the outgoing user messageis in an ALOHA burst format.
 53. The transceiver of claim 52, whereinthe ALOHA burst transmits the outgoing user message at least twice. 54.The transceiver of claim 52, wherein the ALOHA burst is retransmitted amaximum number of times indicated by a message received in the broadcastsignal.
 55. The transceiver of claim 52, wherein the outgoing usermessage contains a bandwidth allocation request.
 56. The transceiver ofclaim 52, wherein the ALOHA burst is a slotted-ALOHA burst aligned withthe transmit frame start time.
 57. The transceiver of claim 52, whereinthe outgoing user message has a size less than a predetermined thresholdvalue.
 58. A method for controlling a return channel from a controlstation, comprising: transmitting a broadcast signal; receiving a returnchannel uplink from a remote user; and setting a return channelbandwidth with a return channel controller which provides a bandwidthallocation message in the broadcast signal.
 59. The method of claim 58,further comprising demodulating the received return channel uplink witha burst channel demodulator controlled by the return channel controller.60. The method of claim 58, wherein the return channel bandwidth is setby evaluating a backlog indicator provided by the remote user in areturn channel message.
 61. The method of claim 60, wherein the returnchannel controller allocates bandwidth if the backlog indicator isgreater than a threshold value.
 62. The method of claim 60, wherein thereturn channel uplink is an ALOHA-type burst message.
 63. The method ofclaim 62, wherein the ALOHA-type burst message is a slotted-ALOHAmessage.
 64. The method of claim 58, wherein the broadcast signal is anasynchronous DVB transport stream.
 65. The method of claim 58, whereinthe return channel uplink is a TDMA signal.
 66. The method of claim 58,wherein the return channel controller controls a frequency of the returnchannel uplink through an assignment message provided to the remote userthrough the broadcast signal.
 67. The method of claim 66, wherein thereturn channel controller changes the frequency of the return channeluplink from a first frequency to a second frequency, said first andsecond frequencies each being within a first return channel group. 68.The method of claim 66, wherein the return channel controller changesthe frequency of the return channel uplink from a first frequency to asecond frequency, said first and second frequencies being within a firstreturn channel group and a second return channel group, respectively.69. The method of claim 58, wherein the return channel bandwidth is setin accordance with a bandwidth allocation request received in the returnchannel uplink.
 70. The method of claim 69, wherein the return channelcontroller assigns periodic bandwidth to the remote user.
 71. The methodof claim 70, wherein the return channel controller assigns a streambandwidth to the remote user.
 72. The method of claim 71, wherein thereturn channel controller assigns a dedicated return channel uplinkfrequency to the remote user.
 73. The method of claim 58, furthercomprising: receiving a plurality of return channel uplinks from aplurality of remote users; and setting a return channel bandwidth foreach of the plurality of return channel uplinks with the return channelcontroller.
 74. The method of claim 73, wherein the return channelcontroller controls a frequency of each of the plurality of returnchannel uplinks through an assignment message.
 75. The method of claim73, wherein setting a return channel bandwidth for each of the pluralityof return channel uplinks includes predicting a return channel trafficload.
 76. The method of claim 73, wherein a return channel bandwidth fora portion of the plurality of return channel uplinks is set using apredicted return channel traffic load, and a return channel bandwidthfor at least one of the plurality of return channel uplinks is set basedupon a bandwidth allocation request transmitted on said at least one ofthe plurality of return channel uplinks.
 77. The method of claim 73,wherein setting a return channel frequency for each of the plurality ofreturn channel uplinks is based on evaluating a traffic load for each ofthe plurality of return channel uplinks.
 78. The method of claim 73,wherein a group load factor for each of a plurality of return channelgroups is periodically transmitted in the broadcast signal.
 79. Themethod of claim 78, wherein a frequency for each of the plurality ofreturn channel uplinks is determined by a corresponding group loadfactor.
 80. The method of claim 78, wherein a bandwidth for each of theplurality of return channel uplinks is determined by a correspondinggroup load factor.
 81. The method of claim 73, wherein setting a returnchannel group for each of the plurality of return channel uplinks isbased on evaluating a traffic load for each of a plurality of returnchannel groups.
 82. A method for transmitting a frame synchronizedmessage, comprising: receiving a control node timing message in abroadcast signal; determining a return channel frame start time usingthe control node timing message; storing an outgoing user message; andtransmitting the outgoing user message during an assigned period afterthe return channel frame start time, wherein a transmit frequency isdetermined by an assignment message received in the broadcast signal.83. The method of claim 82, further comprising evaluating the storedoutgoing user message and transmitting a traffic backlog indicator. 84.The method of claim 82, wherein said assignment message is associatedwith a first return channel group, and said transmit frequency is insaid first return channel group.
 85. The method of claim 84, wherein thetransmit frequency is changed toga different transmit frequency in thefirst return channel group based on said assignment message.
 86. Themethod of claim 84, wherein the transmit frequency is changed to adifferent transmit frequency based on a traffic load factor.
 87. Themethod of claim 82, wherein the transmit frequency is changed from afirst return channel group to a different transmit frequency in a secondreturn channel group.
 88. The method of claim 82, further comprisingchanging the transmit frequency to a different transmit frequency basedon a random weighted frequency selection based on a traffic load factor.89. The method of claim 82, further comprising monitoring a previousreturn channel group and a current return channel group after thetransmit frequency has been assigned to the current return channelgroup.
 90. The method of claim 82, wherein the transmit frequency ischanged to a different transmit frequency a predetermined number offrames after receiving the assignment message.
 91. The method of claim82, wherein the assigned period is determined by a bandwidth allocationmessage received in the broadcast signal.
 92. The method of claim 82,wherein transmitting the outgoing user message includes transmitting anALOHA burst message.
 93. The method of claim 92, wherein the ALOHA bursttransmits the outgoing user message at least twice.
 94. The method ofclaim 93, wherein the ALOHA burst is transmitted a maximum number oftimes as indicated by a message transmitted in the broadcast signal. 95.The method of claim 92, wherein the ALOHA burst message includes abandwidth allocation request.
 96. The method of claim 82, furthercomprising encrypting the outgoing user message.
 97. The method of claim82, wherein the outgoing user message is transmitted in a TDMA format.98. The method of claim 97, wherein transmitting the outgoing usermessage includes transmitting a slotted ALOHA burst message aligned withthe return channel frame start time.
 99. The method of claim 97, whereinthe assigned period includes at least one time slot after the returnchannel frame start time as determined by a bandwidth allocation messagereceived in the broadcast signal.
 100. The method of claim 82, furthercomprising compressing the outgoing user message using a losslesscompression standard.
 101. The method of claim 82, wherein transmittingthe outgoing user message includes modulating the transmit frequencyusing a QPSK modulation scheme.
 102. The method of claim 82, furthercomprising limiting the outgoing user message to a maximum bandwidthless than a stream bandwidth.
 103. A communication system for balancingtraffic on a plurality of return channels, comprising: a control stationto transmit a broadcast signal to a remote user, said broadcast signalincluding a non-real time frame marker, a timing message, and a returnchannel control message; a receiver at the remote user to receive thebroadcast signal and determine a return channel frame start time usingthe non-real time frame marker and the timing message; and a transmitterat the remote user to uplink a user message on one return channel of theplurality of return channels during a predetermined period after thereturn channel frame start time, wherein an uplink frequency of said onereturn channel is determined by the return channel control message. 104.The communication system of claim 103, wherein a bandwidth of said onereturn channel is determined by the return channel control message. 105.The communication system of claim 103, further comprising a returnchannel controller in the control station, said return channelcontroller providing the return channel control message.
 106. Thecommunication system of claim 105, wherein the return channel controllerfurther provides a bandwidth allocation message in the broadcast signalwhich sets a bandwidth of said one return channel.
 107. Thecommunication system of claim 106, wherein the bandwidth of said onereturn channel is set based on a predicted load factor.
 108. Thecommunication system of claim 105, wherein the bandwidth of said onereturn channel is set by evaluating a user backlog indicator transmittedby the remote user to the control station.
 109. The communication systemof claim 108, wherein the bandwidth of said one return channel is set toa stream bandwidth.
 110. The communication system of claim 108, whereinthe uplink frequency of said one return channel is set to a dedicatedfrequency based on an evaluation of the user backlog indicator.
 111. Thecommunication system of claim 105, wherein the return channel controllerchanges the uplink frequency to a different frequency within a firstreturn channel group.
 112. The communication system of claim 105,wherein the return channel controller changes the uplink frequency to adifferent frequency within a second return channel group.
 113. Thecommunication system of claim 112, wherein the return channel controllerchanges the uplink frequency to a different frequency based on a systemload factor.
 114. The communication system of claim 103, wherein abandwidth of said one return channel is determined by a bandwidthallocation request included in the user message uplinked by the remoteuser.
 115. The communication system of claim 114, wherein the usermessage is an ALOHA-type burst transmission.
 116. The communicationsystem of claim 115, wherein the user message includes the bandwidthallocation request and an additional user message, said additional usermessage having a size less than a predetermined threshold size.
 117. Thecommunication system of claim 103, wherein said broadcast signal is anasynchronous DVB transport stream.
 118. The communication system ofclaim 103, further comprising a plurality of remote users sharing theplurality of return channels and a return channel controller, whereinthe return channel controller controls the uplink frequency of each ofthe plurality of return channels through the return channel controlmessage.
 119. The communication system of claim 118, wherein said returnchannel controller controls a bandwidth allocation for each of theplurality of return channels.
 120. The communication system of claim118, wherein a subset of the plurality of return channels are ALOHAburst channels, and wherein said return channel controller shifts aremote user uplink from an ALOHA burst channel to a non-ALOHA burstchannel in accordance with the return channel control message.
 121. Thecommunication system of claim 120, wherein the ALOHA burst channel isselected from the subset of the plurality of return channels by theremote user using a random weighted frequency selection criteria. 122.The communication system of claim 120, wherein said non ALOHA burstchannel is selected by the control station using a group load factor.123. The communication system of claim 103, wherein said broadcastsignal is encapsulated in an IP/DVB protocol layer.
 124. Thecommunication system of claim 103, further comprising a communicationsatellite to relay the transmitted broadcast signal to the receiver.125. A method for balancing loads among and between groups of returnchannels in a communication system, comprising: requesting returnchannel bandwidth in an uplink message from a remote user to a controlstation, said uplink message including a backlog indicator; allocatingat least a return channel bandwidth for the remote user by processingthe backlog indicator; providing a channel allocation message from thecontrol station to the remote user in a broadcast signal, wherein thechannel allocation message at least allocates the return channelbandwidth; and transmitting a user message on a return channel inaccordance with the channel allocation message.
 126. The method of claim125, further comprising allocating a return channel uplink frequency.127. The method of claim 126, wherein allocating the return channeluplink frequency includes changing an uplink frequency from a firstfrequency to a second frequency.
 128. The method of claim 127, whereinthe uplink frequency is changed to balance a traffic load between thegroups of return channels.
 129. The method of claim 127, wherein theuplink frequency is changed based on a group load factor.
 130. Themethod of claim 127, wherein the first frequency and the secondfrequency are assigned to a first return channel group.
 131. The methodof claim 127, wherein the first frequency and the second frequency areassigned to a first return channel group and a second return channelgroup, respectively.
 132. The method of claim 126, wherein allocatingthe return channel uplink frequency includes frequency hopping an uplinkfrequency between a predetermined number of uplink frequencies inaccordance with a dynamic system traffic load.
 133. The method of claim132, wherein allocating the return channel uplink frequency by frequencyhopping further depends on a plurality of backlog indicators from aplurality of remote users.
 134. The method of claim 132, wherein thepredetermined number of uplink frequencies are assigned to a returnchannel group.
 135. The method of claim 132, wherein frequency hoppingbalances a traffic load within a first return channel group.
 136. Themethod of claim 125, wherein requesting return channel bandwidthincludes transmitting an ALOHA burst transmission from the remote user.137. The method of claim 125, wherein the return channel bandwidth isallocated to at least allow a user message smaller than a predeterminedthreshold size to be uplinked.
 138. The method of claim 125, wherein aportion of available return channels are ALOHA-burst return channels.139. The method of claim 125, wherein the control station periodicallytransmits a group load factor for each of the groups of return channels.140. The method of claim 125, wherein requesting return channelbandwidth includes transmitting a first ALOHA-type burst transmissionfrom the remote user on an ALOHA channel.
 141. The method of claim 125,further comprising the remote user selecting the return channel from oneof the groups of return channels by using a random weighting factorbased on a system traffic load.